第二次停下來回顧,這次看 Day 11 到 Day 19——從最基礎的 Windows Security 事件講到今天做出真的能跑的 dashboard。跟第一次小結一樣,不重貼摘要,想講三件事:哪裡卡住、哪個判斷被修正、接下來要注意什麼。

這九天,我最常做的一件事是「先查證再寫」
回頭看,這段時間跟前十天比,有一個明顯的行為轉變：至少三次,我在動筆之前先去查證排程原本設想的角度對不對,結果發現對不上。

這個習慣我覺得比任何單一篇的內容都重要——它把「查證」這件事,從寫完之後才做的檢查,往前挪到動筆之前。前十天比較常是先寫、後來才發現要修正;這九天比較常是先查、發現不對就直接換角度寫,不會先寫出一個後來要打臉的版本。

一個被修正的方向：悲觀的猜測不一定是對的
Day 19 有個很具體的例子：我預測 Top IP、Top 帳號的聚合查詢會因為欄位型別問題失敗,還特地寫了容錯機制去接住這個預期中的錯誤。 結果完全沒發生,腳本第一次跑就順利執行。

這跟 Day 9「猜錯噪音是全面性問題」剛好是相反方向的錯誤——那次是猜得太樂觀,這次是猜得太悲觀。 兩次的共同教訓是一樣的：猜測終究只是猜測,不管猜的方向是樂觀還是悲觀,都要拿真實結果驗證,不能因為「這次猜對了」或「這次猜錯了方向」就改變下次的查證習慣。

一個反覆出現的主題：同樣的形狀,不一定是同一件事
這九天裡,這個主題冒出來好幾次,值得單獨拉出來講：Day 9 那條等級最高的規則其實是磁碟清理;Day 16 提到失敗後成功的型態,惡意跟良性長得一模一樣;Day 19 做完 dashboard,唯一浮出來的高風險事件,是 Wazuh Manager 自己被連續打錯 sudo 密碼,不是我原本設想要保護的 Windows 靶機。

三次不同的場景,同一個道理：告警的形狀本身不能告訴你這是不是真的攻擊,要看背景脈絡。 這件事在 Day 9 就講過一次,但 Day 19 那次讓我意識到,這個道理不只適用在「規則會不會誤判」,也適用在「我以為自己在保護什麼」這個更根本的假設上——我一直預設威脅會出現在 Windows 靶機那邊,結果第一個浮出來的訊號,反而是監控系統自己...

還沒解決、而且接下來大概不會回頭補的缺口
Day 6 提到的 PowerShell 通道還沒加進 Wazuh 採集設定,到 Day 14 又確認了一次還是沒補。 接下來系列要轉進 AI 段,這個 Windows 端的缺口,大概率整個系列剩下的篇幅都不會回頭處理了... 絕對不是忘記哈,是接下來的優先順序不在這裡。

接下來 10 天怎麼安排？
剩下 Day 21 到 Day 30,Day 30 是收尾,所以實質上是 9 篇。這個組別叫 AI Security,我想藉這次小結,把接下來的安排交代清楚。

Day 21(事件回應 SOP、報告分眾)講完之後,Day 22 到 Day 29 這 8 天全部會在 AI 這條線上——從「AI 在 SOC 該做什麼、不該做什麼」的邊界,到欄位怎麼餵給 AI、分析管線設計、RAG 知識庫,一路到防幻覺規格、把 Wazuh 接給 AI 查詢的 MCP 整合,以及我去稽核自己在用的那個 MCP server。

明天先把事件回應那段收尾,後天正式進 AI 這條主線。

感謝看到這邊的你，明天見~